In light of the fact that it seems possible to fit the plastic caps of a Debian branded Swiss Army Knife (Last orders today!) on an existing Swiss Army Knife (German written howto as PDF), I started to think about which Victorinox Cybertool would be the best fitting for me. And because the Victorinox comparison page doesn t really show diffs, just columns with floating text which are not very helpful for generating diffs in your head, I used command line tools for that purpose: wdiff Because the floating texts are not line- but just whitespace-based, the tool of choice is not diff but wdiff, a word-based diff. It encloses additions and removals in + + and [- -] blocks. (No, those aren t Japanese smileys although they look a lot like some. ^^). The easiest and clearest way is to copy and paste the texts from Victorinox comparison page into some text files and compare them with wdiff:

$ wdiff cybertool34.txt cybertool41.txt
+Schraubendreher 2.5mm,+ Pinzette, N hahle mit Nadel hr, +Holzs ge,+ Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), Kombizange( H lsenpresser, Drahtschneider ), Stech-Bohrahle, Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), +Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), +Holzmeissel / Schaber,+ Bit-Halter, Stecknadel, inox, Schere, Korkenzieher, Zahnstocher

So this already extracted the information which are the seven tools which are in the Cybertool 41, but not in the Cybertool 34. Nevertheless the diff is still not easily recognizable on the first glance. There are several ways to help here. First wdiff has an option --no-common (the according short option is -3) which just shows added and removed words:

$ wdiff -3 cybertool34.txt cybertool41.txt
======================================================================
 +Schraubendreher 2.5mm,+ 
======================================================================
  +Holzs ge,+ 
======================================================================
  +Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ 
======================================================================
  +Holzmeissel / Schaber,+ 
======================================================================

This is already way better to quickly recognize the actual differences. But if you still also want to see the common tools of the two knifes you need some visual help: One option is to use wdiff s --terminal (or short -t) option. Added words are then displayed inverse and removed words are shown underlined (background and foreground colors hardcoded as there is no invert colors style in CSS or HTML):

$ wdiff -t cybertool34.txt cybertool41.txt
Schraubendreher 2.5mm, Pinzette, N hahle mit Nadel hr, Holzs ge, Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), Kombizange( H lsenpresser, Drahtschneider ), Stech-Bohrahle, Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ), Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, Druckkugelschreiber, Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), Holzmeissel / Schaber, Bit-Halter, Stecknadel, inox, Schere, Korkenzieher, Zahnstocher

But some still like to to use color instead of the contrast-rich inverse and the easily to oversee underlining. This is where colordiff comes into play: colordiff colordiff is like syntax highlighting for diffs on the command line. I works with classic and unified diffs as well as with wdiffs and debdiffs (the debdiff command is part of the devscripts package).

$ wdiff cybertool34.txt cybertool41.txt colordiff
+Schraubendreher 2.5mm,+ Pinzette, N hahle mit Nadel hr, +Holzs ge,+ Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), Kombizange( H lsenpresser, Drahtschneider ), Stech-Bohrahle, Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), +Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), +Holzmeissel / Schaber,+ Bit-Halter, Stecknadel, inox, Schere, Korkenzieher, Zahnstocher $ wdiff cybertool29.txt cybertool41.txt colordiff
+Schraubendreher 2.5mm,+ Pinzette, N hahle mit Nadel hr, +Holzs ge,+ Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), +Kombizange( H lsenpresser, Drahtschneider ),+ Stech-Bohrahle, +Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, [-Druckkugelschreiber,-] Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), +Holzmeissel / Schaber,+ Bit-Halter, Stecknadel, inox, +Schere,+ Korkenzieher, Zahnstocher

(Coloured Screenshots done with ANSI HTML Adapter from the package aha.) Some, especially those who are used to git, are probably confused by the default choice of diff colors. This is easily fixable by writing the following into you ~/.colordiffrc:

newtext=green
oldtext=red
diffstuff=darkblue
cvsstuff=darkyellow

(See also /etc/colordiff for the defaults and hints.) colordiff has by the way two operating modes:

• Without parameter it reads diffs from standard input as seen above.
• With parameters it works as drop-in diff replacement including all diff options as shown below.

So now let us compare the Cybertool 29 with Cybertool 34 in a normal diff (by using the texts from above and replacing all commata with newline characters) with git-like colors:

$ colordiff cybertool29-lines.txt cybertool34-lines.txt
12a13,14
> Kombizange( H lsenpresser
> Drahtschneider )
13a16,17
> Kugelschreiber( auch zum DIP-Switch verstellen )
> Mehrzweckhaken (Pakettr ger)
16d19
< Druckkugelschreiber
25a29
> Schere

Or as unifed diff with some context:

$ colordiff -u cybertool29-lines.txt cybertool34-lines.txt
--- cybertool29-lines.txt     2011-08-31 20:55:37.195546238 +0200
+++ cybertool34-lines.txt   2011-08-31 20:55:11.667710504 +0200
@@ -10,10 +10,13 @@
 Bit Torx 8
 Bit Torx 10
 Bit Torx 15 )
+Kombizange( H lsenpresser
+Drahtschneider )
 Stech-Bohrahle
+Kugelschreiber( auch zum DIP-Switch verstellen )
+Mehrzweckhaken (Pakettr ger)
 Dosen ffner( kleiner Schraubendreher )
 Kleine Klinge
-Druckkugelschreiber
 Grosse Klinge
 Ring
 inox
@@ -23,5 +26,6 @@
 Bit-Halter
 Stecknadel
 inox
+Schere
 Korkenzieher
 Zahnstocher

So if you want nicely colored diffs with Subversion like you re used to with git, you can use svn diff colordiff.

Everyone loves stats, ok well at least I do. I was doing some research with regards to package maintenance within the Debian distribution and since the results might be interesting for someone else there we are. On 19th of August 2011 there have been:

• 16935 unique source packages in Debian/sid
• 9977 packages with Vcs-* field in Debian/sid
• 6957 packages without a Vcs-* field in Debian/sid

Therefore ~59% of all packages in Debian/sid are officially managed with a version control system (VCS). Now, which VCS do those packages use?

1. Svn: 4939
2. Git: 4377
3. Darcs: 284
4. Bzr: 247
5. Hg: 61
6. Cvs: 31
7. Arch: 28
8. Mtn: 10

I ve retrieved the numbers from the Ultimate Debian Database (UDD). Sadly there s a bug in UDD regarding the Vcs-Type information, see #637524. Therefore I ve extracted a list of 80 packages where a Vcs-Browser header is available but the Vcs-Type entry is empty in UDD. 29 packages of them are managed inside CVS but don t appear as such in UDD, so I manually corrected the number for CVS in the numbers above. The remaining 51 packages have a Vcs-Browser field set but lack the according Vcs-* entry, some of them pointing to upstream VCS instead of the according Debian package repository, some of them result in 404 errors, etc. As a result I ve reported bugs where applicable (#638466, #638468, #638469, #638470, #638471, #638472, #638474, #638475, #638476, #638477, #638479, #638482, #638486, #638488, #638493, #638497, #638501, #638475, #638475, #638502, #638503, #638505, #638506, #638508, #638509, #638510, #638511, #638512, #638513, #638516, #638518, #638519, #638520, #638522, #638523, #638524, #638525, #638526, #638527, #638528, #638529, #638530, #638516, #638531). Disclaimer: I found Debian s Statistics wiki page and Zack s VCS usage stats after starting to play with my own stats. AFAICT Zack s slightly higher numbers are the result of looking at multiple versions for the same source packages, as you ll see when comparing numbers from UDD s sources_uniq view (which I used) with either 1) UDD s sources table, 2) source table count from projectb or 3) Package count from http://$DEBIAN_MIRROR/debian/dists/unstable/ main,contrib,non-free /source/Sources.bz2. Conclusion: 9316 packages are officially managed with Subversion and Git as of today, representing ~94% of the VCS managed packages. This means ~55% of all the Debian (source) packages are available through either a Git or Subversion repository and that s actually the number I was originally interested in. Thanks to Alexander Wirt, Christian Hofstaedter, Gerfried Fuchs, J rg Jaspert and Michael Renner for hints in forming up the final stats results.

The ability to connect a 3G modem to a wireless router to form a Internet connected ad-hoc network of machines is very powerful. I ve done this many times and have written about it before (e.g., see my OpenWRT writeup page) but I recently did it with modern hardware again. Here I will use the TP-Link TL-WR1043ND wireless router (available here for around $50) together with the Huawei E367 3G UMTS/HSDPA modem. Other wireless routers and modem should work fine. The software is OpenWRT 10.03 although I hope to redo this with LibreWRT eventually. My writeup is mostly focused around what is happening around the prompt, so it is mostly a cut n'paste terminal session with a comment interlined.


The first step is to flash the firmware with OpenWRT. The OpenWRT wiki page for the TL-WR1043ND covers this in detail, and for any other hardware you should find what you need in the OpenWRT wiki. If you have already installed OpenWRT on the TL-WR1043ND, and want to wipe it out and start from scratch (like I did for this writeup) here is how to do it:

root@choco:~# cd /tmp
root@choco:/tmp# wget http://downloads.openwrt.org/backfire/10.03/ar71xx/openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin
Connecting to downloads.openwrt.org (78.24.191.177:80)
openwrt-ar71xx-tl-wr 100%  *******************************   2688k 00:00:00 ETA
root@choco:/tmp# md5sum openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin
9927973ba5da65d0d52e255397452b87  openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin
root@choco:/tmp# mtd -r write /tmp/openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin firmware
Unlocking firmware ...
Writing from /tmp/openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin to firmware ...
Rebooting ...

The device will reboot automatically when it is done. After say 30 seconds, try to connect to it using the default IPv4 address 192.168.1.1. I have connected the WAN port to the Internet and connect to the router over local network connected to the router s LAN1 input. Let s configure OpenWRT, I m calling the host choco and giving it the IPv4 address 192.168.1.46. I ll also set a good root password to disable telnet, and add some SSH keys to simplify remote login.

jas@latte:~$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
 === IMPORTANT ============================
  Use 'passwd' to set your login password
  this will disable telnet and enable SSH
 ------------------------------------------
BusyBox v1.15.3 (2010-04-06 03:14:11 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
  _______                     ________        __
          .-----.-----.-----.          .----.    _
     -      _     -__                   _    _ 
  _______    __ _____ __ __ ________ __    ____ 
           __  W I R E L E S S   F R E E D O M
 Backfire (10.03, r20728) --------------------------
  * 1/3 shot Kahlua    In a shot glass, layer Kahlua
  * 1/3 shot Bailey's  on the bottom, then Bailey's,
  * 1/3 shot Vodka     then Vodka.
 ---------------------------------------------------
root@OpenWrt:/# passwd
Changing password for root
New password:
Retype password:
Password for root changed by root
root@OpenWrt:/# sed -i -e 's/OpenWrt/choco/' /etc/config/system
root@OpenWrt:/# sed -i -e 's/192.168.1.1/192.168.1.46/' /etc/config/network
root@OpenWrt:/# cat>/etc/dropbear/authorized_keys
ssh-rsa AAAAB3NzaC1yc2...
^D
root@OpenWrt:/# dropbearkey -y -f /etc/dropbear/dropbear_rsa_host_key
Public key portion is:
ssh-rsa AAAA... root@OpenWrt
Fingerprint: md5 45:fd:62...
root@OpenWrt:/#

You could reboot the machine here to switch from telnet to SSH, but I ll install a bunch of packages while I m at it. Run opkg update to update the package list, and then install the wireless modules for the TL-WR1043ND.

root@OpenWrt:/# opkg update
Downloading http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/Packages.gz.
Inflating http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/packages.
root@OpenWrt:/# opkg install kmod-ath9k wpad-mini
...
Configuring iw.
Configuring kmod-crypto-core.
Configuring kmod-crypto-arc4.
Configuring kmod-crypto-aes.
Configuring wireless-tools.
Configuring kmod-cfg80211.
Configuring kmod-mac80211.
Configuring kmod-ath.
Configuring kmod-ath9k.
Configuring crda.
Configuring wpad-mini.
root@OpenWrt:/#

Next I ll install some packages that will are needed for the modem.

root@OpenWrt:/# opkg install comgt kmod-usb-serial kmod-usb2 kmod-usb-uhci kmod-usb-ohci usb-modeswitch
...
Configuring kmod-nls-base.
Configuring kmod-usb-core.
Configuring chat.
Configuring kmod-usb-ohci.
Configuring kmod-usb2.
Configuring comgt.
Configuring usb-modeswitch.
Configuring kmod-usb-serial.
Configuring kmod-usb-uhci.
root@OpenWrt:/#

Now let s reboot the machine and try to get things to really work.

root@OpenWrt:/# sync
root@OpenWrt:/# reboot

Use SSH to connect to the router, and don t forget the use its new IPv4 address! 3G modems are notoriously known for not acting as a modem directly. Instead they often simulate a CD-ROM that will install device driver software, for inferior operating systems. Fortunately the usb_modeswitch tool fixes the hardware for us. My Huawei E367 start up with the USB vendor/product IDs 0x12d1:0 1446, you normally find this out by looking in /proc/bus/usb/devices. Here is the output on my device:

root@choco:~# cat /proc/bus/usb/devices
...
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1446 Rev= 0.00
S:  Manufacturer=Huawei Technologies
S:  Product=HUAWEI Mobile
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
root@choco:~#

This means I have to go find a usb-modeswitch configuration for this device. Fortunately, I found it on my Debian Squeeze box in /etc/usb_modeswitch.d/12d1:1446 (from the usb-modeswitch-data package). There was a slight problem with the file, it didn t specify the correct USB vendor/product ID of the device after it has been switched . My Huawei E367 switches to 12d1:1506, so I add 1506 to the TargetProductList list. Here is the final configuration:

root@choco:~# cat>/etc/usb-modeswitch.conf
EnableLogging=1
DefaultVendor= 0x12d1
DefaultProduct=0x1446
TargetVendor=  0x12d1
TargetProductList="1001,1406,140b,140c,1412,141b,14ac,1506"
CheckSuccess=20
MessageContent="55534243123456780000000000000011062000000100000000000000000000"
root@choco:~#

Now you should be able to run usb_modeswitch to perform the switch :

root@choco:~# usb_modeswitch 
Looking for target devices ...
 No devices in target mode or class found
Looking for default devices ...
 Found default devices (1)
Accessing device 002 on bus 001 ...
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
 No driver found. Either detached before or never attached
SCSI inquiry data (for identification)
-------------------------
  Vendor String: HUAWEI
   Model String: Mass Storage
Revision String: 2.31
-------------------------
USB description data (for identification)
-------------------------
Manufacturer: Huawei Technologies
     Product: HUAWEI Mobile
  Serial No.: not provided
-------------------------
Setting up communication with interface 0 ...
Trying to send the message to endpoint 0x01 ...
 OK, message successfully sent
Checking for mode switch (max. 20 times, once per second) ...
 Waiting for original device to vanish ...
 Original device can't be accessed anymore. Good.
 Searching for target devices ...
 Searching for target devices ...
 Searching for target devices ...
 Searching for target devices ...
 Searching for target devices ...
 Found correct target device
Mode switch succeeded. Bye.
root@choco:~#

The /proc/bus/usb/devices file will now contain information about the real device:

root@choco:~# cat /proc/bus/usb/devices
...
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1506 Rev= 0.00
S:  Manufacturer=Huawei Technologies
S:  Product=HUAWEI Mobile
C:* #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
A:  FirstIf#= 1 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=(none)
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=(none)
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
root@choco:~#

Let s put that command in /etc/rc.local so that it will be run on every boot.

root@choco:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
/usr/bin/usb_modeswitch
exit 0
root@choco:~#

We are not quite ready, the usbserial module needs to be told which USB vendor/product to use. The /etc/modules.d/60-usb-serial file is used during boot to set the right parameters. You can also run rmmod followed by insmod with the proper parameters to avoid a reboot. You can use the gcom info tool to find some information about the modem. Normally you use /dev/ttyUSB0 but for some reason it does not work for me and instead I had to use /dev/ttyUSB3.

root@choco:~# cat>/etc/modules.d/60-usb-serial
usbserial vendor=0x12d1 product=0x1506 maxSize=4096
root@choco:~# rmmod usbserial
root@choco:~# insmod usbserial vendor=0x12d1 product=0x1506 maxSize=4096
root@choco:~# gcom -d /dev/ttyUSB3 info
##### Wireless WAN Modem Configuration #####
Product text:
====
Manufacturer: huawei
Model: E367
Revision: 11.807.05.00.00
IMEI: 353613040739180
+GCAP: +CGSM,+DS,+ES
OK
====
Manufacturer:           huawei
IMEI and Serial Number: 353613040739180
Manufacturer's Revision:
11.807.05.00.
Hardware Revision:      NOT
Network Locked:         ERROR:
Customisation:          NOT SUPPORT
Band settings:          (NOT)
APN:                    ERROR:
##### END #####
root@choco:~#

Let s configure network and wireless. The configurations files are /etc/config/network and /etc/config/wireless. Edit them using your favorite editor, or vi. I m setting up a PSK2 encrypted WLAN and I have a WDS to connect two wireless routers. Note that you need to use the correct PIN for your SIM card (here I m using 8328) and set the APN correctly (I m using bredband.tre.se ). Reboot after making these changes.

root@choco:~# cat /etc/config/network
config 'interface' 'loopback'
       option 'ifname'   'lo'
       option 'proto'    'static'
       option 'ipaddr'   '127.0.0.1'
       option 'netmask'  '255.0.0.0'
config 'interface' 'lan'
        option 'ifname'   'eth0.1'
        option 'type'     'bridge'
        option 'proto'    'static'
        option 'ipaddr'   '192.168.1.46'
        option 'netmask'  '255.255.255.0'
#config 'interface' 'wan'
#        option 'ifname' 'eth0.2'
#        option 'proto' 'dhcp'
config 'switch'
	option 'name' 'rtl8366rb'
        option 'reset' '1'
        option 'enable_vlan' '1'
config 'switch_vlan'
        option 'device' 'rtl8366rb'
        option 'vlan' '1'
        option 'ports' '1 2 3 4 5t'
config 'switch_vlan'
        option 'device' 'rtl8366rb'
        option 'vlan' '2'
        option 'ports' '0 5t'
config interface wan
        option ifname   ppp0
        option proto    3g
        option device   /dev/ttyUSB0
        option apn      bredband.tre.se
        option pincode  8328
root@choco:~# cat /etc/config/wireless
config wifi-device  radio0
	option type     mac80211
	option channel  5
	option macaddr	00:27:19:fc:87:b2
	option hwmode	11ng
	option htmode	HT20
	list ht_capab	SHORT-GI-40
	list ht_capab	DSSS_CCK-40
config wifi-iface
	option device   radio0
	option network  lan
	option mode     ap
	option ssid     Grisslan
	option encryption psk2
	option key	  notforyoutosee
config wifi-iface
        option device     radio0
        option network    lan
        option mode       wds
        option bssid      00:1F:C6:60:D3:11
        option ssid       GrisslanWDS
        option encryption psk2
        option key        thisisalsosecret
root@choco:~# reboot
root@choco:~#

Once the machine have rebooted, you can bring up the 3G connection by using ifup wan . Look at the log by using logread and tail the log in the background by doing logread -f & .

root@choco:~# ifup wan
Trying to set PIN
PIN set successfully
root@choco:~# logread  tail -20
May 21 13:41:20 choco local2.info chat[2419]: send (ATD*99***1#^M)
May 21 13:41:20 choco local2.info chat[2419]: expect (CONNECT)
May 21 13:41:20 choco local2.info chat[2419]: ^M
May 21 13:41:20 choco local2.info chat[2419]: ATD*99***1#^M^M
May 21 13:41:20 choco local2.info chat[2419]: CONNECT
May 21 13:41:20 choco local2.info chat[2419]:  -- got it
May 21 13:41:20 choco local2.info chat[2419]: send ( ^M)
May 21 13:41:20 choco daemon.info pppd[2412]: Serial connection established.
May 21 13:41:20 choco daemon.info pppd[2412]: Using interface ppp0
May 21 13:41:20 choco daemon.notice pppd[2412]: Connect: ppp0 <--> /dev/ttyUSB0
May 21 13:41:24 choco daemon.warn pppd[2412]: Could not determine remote IP address: defaulting to 10.64.64.64
May 21 13:41:24 choco daemon.notice pppd[2412]: local  IP address 95.209.96.115
May 21 13:41:24 choco daemon.notice pppd[2412]: remote IP address 10.64.64.64
May 21 13:41:24 choco daemon.notice pppd[2412]: primary   DNS address 80.251.201.177
May 21 13:41:24 choco daemon.notice pppd[2412]: secondary DNS address 80.251.201.178
May 21 13:41:24 choco daemon.info dnsmasq[1028]: reading /tmp/resolv.conf.auto
May 21 13:41:24 choco daemon.info dnsmasq[1028]: using nameserver 80.251.201.178#53
May 21 13:41:24 choco daemon.info dnsmasq[1028]: using nameserver 80.251.201.177#53
May 21 13:41:24 choco daemon.info dnsmasq[1028]: using local addresses only for domain lan
May 21 13:41:25 choco user.notice rdate: Synced with ptbtime1.ptb.de
root@choco:~#

Hooray! Or almost so usually the first time you connect, I often get incorrect DNS servers from the server. It shows up like this in the log:

May 21 12:25:04 choco daemon.notice pppd[1157]: primary   DNS address 10.11.12.13
May 21 12:25:04 choco daemon.notice pppd[1157]: secondary DNS address 10.11.12.14

The exact reason why this happens is beyond me. There are patches floating around for pppd, but I haven t tried them. A common workaround is to hardcode static DNS servers (like Google DNS or OpenDNS). I have come up with my own workaround, based on the observation that when the problem has occurred it will not happen again if I disconnect and reconnect. Thus I have written a small script which is invoked whenever an interface is brought up (typically the WAN interface).

# Written by Simon Josefsson May 2011.
root@choco:~# cat> /etc/hotplug.d/iface/01-reconnect-if-dns-is-broken
case "$ ACTION:-ifup " in
    ifup)
	    if grep -q 10.11.12.13 /tmp/resolv.conf.auto; then
		(sleep 30 && ifdown wan && ifup wan) &
	    fi
	    ;;
esac
root@choco:~# chmod +x /etc/hotplug.d/iface/01-reconnect-if-dns-is-broken
root@choco:~#

That s it! If you found this writeup useful, please flattr it.

I just found this out, so I'm posting it, since it might be useful both as a reminder, and for others to read. Suppose you have a "classical" Subversion web interface, like svn.openstreetmap.org. This will show you the last revision by default. What if you want to see a particular revision? I found this by googling a bit:

http://<yoursvn>/!svn/bc/<revision>/<path>

So, say, using the above example, you want to see the sites/ directory of revision 20000: here you are (compare with current). This obviously works with files too.

On the last weekend my team and I participated in the Mobile App Camp (link in Lithuanian) organized by Omnitel, which is one of the dominant mobile operators in Lithuania. The event seems to be part of Omnitel's push for increasing the share of smartphones in the Lithuanian market, which has been lagging behind the European trends.

Our team consisted of Povilas Kytra, who is behind the TV.LT project, Mantas Kanaporis from A-Gain and me. In the weekend we built an app that shows the TV programme for the coming day for all the Lithuanian TV channels. (The app is not yet available on the Android Market, but we are working on it.)

Here's a screenshot of the main screen of the application:

Daily builds As of a month ago there are Ubuntu archives with fresh packages of Samba 4 and Openchange, built on a daily basis day from the latest upstream revision. This means that it is now possible to run a version of Samba 4 that is less than 24 hours old, without having to know how to extract source code from the version control system that upstream is using, without having to know how to build and install an application from source, but perhaps most importantly: without having to go through the tedious process of manually updating the source code and rebuilding. OpenChange is tightly coupled to Samba 4, so installing a new version of OpenChange usually involves installing a new version of Samba 4 as well. To make matters more confusing, the two projects use different version control systems (Samba 4 is in Git, while OpenChange is in Subversion) and different build systems (Samba 4 uses waf, OpenChange uses autoconf and make). I have been involved in Samba 4 and OpenChange as an upstream developer and more recently also as a packager for both Debian and Ubuntu. As an upstream developer for both these projects it is important for me that users can easily run the development versions. It makes it possible for interested users to confirm the fixes for issues they have reported and to test new features. The more users run the development version, the more confident I can be as a developer that doing a release will not cause any unexpected surprises. As a packager it is useful to know when there are upstream changes that are going to break my package with the next release.

Recipes The daily builds work using so-called recipes which describe how to build a Debian source package from a set of Bazaar branches. For example, the Samba 4 recipe looks like this:

# bzr-builder format 0.2 deb-version 4.0.0~alpha14~bzr revno ~ppa revno:packaging + revno:debian 
lp:samba
merge debian lp:~samba-team/samba/unstable
merge packaging lp:~samba-team/samba/4.0-ppa-maverick

This dictates that a source package should be built by taking the upstream Samba branch and merging the Debian packaging and some recipe-specific tweaking. The last bit on the first line indicates the version string to be used when generating a changelog entry for the daily build. Every night Launchpad (through bzr-builder) merges these branches and attempts to build the resulting source package, e-mailing me in case of build problems. Generally I fix issues that come up by committing directly to upstream VCS or to the Debian packaging branch. There is no overhead in maintaining the daily build after I've set it up. For more information on creating source package recipes, see getting started.

Toolchain The entire toolchain that does the daily package builds for Ubuntu is Free Software, and I have contributed to various bits of that toolchain over the years. It's exciting to see everything come together.

Soyuz Launchpad consists of multiple pillars - one of those pillars is Soyuz, which I hack on as part of my day job at Canonical. Soyuz is responsible for the archive management and package building. Debian source packages (a combination of upstream source code and packaging metadata) get uploaded by users and then built for various architectures on our buildfarm and published to the Ubuntu archive or to users personal package archives.

Launchpad-code Another pillar of Launchpad is Launchpad-code, which is responsible for the hosting and management of version control branches. Launchpad users can either host their branches on Launchpad directly or mirror branches (either native Bazaar branches or branches in a foreign format such as Subversion, Git or Mercurial). The mirrorring of native and foreign branches happens using standard Bazaar API's. In the case of Samba and OpenChange we import the branches of the upstream projects (Samba is in Git, OpenChange is in Subversion) and the packaging for both projects is in Bazaar. Launchad-code calls out to Bazaar to do the actual mirrorring. Over the last few years I have done a lot of work to improve Bazaars support for foreign branches, in particular on supporting Subversion, Git and Mercurial. As the code mirrorring in Launchpad is one of the biggest users of bzr-svn and bzr-git it has helped find some of the more obscure bugs in those plugins over the last few years, to the point where there are only a handful of issues with Git and Subversion imports left.

bzr-git and dulwich bzr-git provides transparent access to Git repositories from within Bazaar and is built on top of Dulwich. Dulwich is a Python library that provides access to the Git file formats and protocols that is completely independent of Bazaar. James Westby originally started it and I adopted it for bzr-git and further extended it. There are now several other projects that use it as well, including hg-git, and rabbitvcs. Apart from James and me almost two dozen other people have contributed it so far.

bzr-svn and subvertpy bzr-svn provides transparant access to Subversion repositories in Bazaar. When I grew frustrated with the existing Subversion Python bindings for various reasons, I decided to create independent Python bindings for Subversion from scratch. These bindings have since been split out into a separate project - subvertpy - and other projects have since also started using them, e.g. hgsubversion and basie.

Using the daily builds To use the Samba 4 and OpenChange daily builds (Ubuntu Maverick only for now), run:

$ apt-add-repository ppa:samba-team/ppa
$ apt-add-repository ppa:openchange/daily-builds

cp: Karnivool - Themata

Oddly, I have had four different people ask me about the best way to begin a Django project or setup their system to make it easy to develop with Django. Since I've now given my response via email so many times, I figure I might as well broadcast it and hopefully this will help others as well My assumptions:

• Using Linux (or a Unix machine)
• Single developer with root access (quite possibly a laptop)
• Knowledge of DVCSes (e.g. git / hg / bzr )

What we will do is create a private binary directory and another Python modules. Then take a checkout of the two most important Django projects, and make them work. First: create your user

$ sudo adduser newbie
$ ssh localhost -l newbie
$ whoami
newbie

Then we want to create some local bin and lib directories. First the binary directory $ mkdir ~/bin # On Ubuntu/Debian, this will automatically be in your PATH the next time you login And now a local directory for our various libraries

$ mkdir -p ~/lib/python
$ echo "PYTHONPATH=~/lib/python:" >> ~/.bashrc
$ echo "export PYTHONPATH" >> ~/.bashrc

This will add that directory to our Python path. If you happen to also use another language you can put things into ~/lib/ruby, ~/lib/perl as appropriate

$ mkdir ~/Projects
$ cd ~/Projects

Here is where we will store copies of upstream software. What is the reason for using the repositories rather than packages? This allows us to checkout specific versions to match what our clients might be using. Or test things against newer versions of the upstream project. First, let's setup Django. I tend to use git by default, especially if the upstream is using Subversion. If they are using Mercurial or Bazaar, I use those directly.

$ git svn clone -s http://code.djangoproject.com/svn/django/
Initialized empty Git repository in /home/newbie/Projects/django/.git/
Using higher level of URL: http://code.djangoproject.com/svn/django => http://code.djangoproject.com/svn
r1 = 5cda37203ffa6ea83da2958a95c377984482877f (refs/remotes/trunk)
	A	django-docs/images/flatfiles_admin.png
	A	django-docs/images/users_changelist.png
	A	django-docs/model-api.txt
	A	django-docs/build.py
	A	django-docs/db-api.txt
	A	django-docs/writing-apps-guide-outline.txt
	A	django-docs/templates.txt
r2 = b8249ac45e2154933b9649fd8181d5769e31c9fc (refs/remotes/trunk)
	A	django/utils/feedgenerator.py
	A	django/utils/datastructures.py
[...]
r13399 = f3902c67a3b8788de2145899e435a394c512b455 (refs/remotes/releases)
	M	tests/regressiontests/m2m_through_regress/tests.py
r13400 = cd72207306a5a4eecdf07f65c109f37c8317ed81 (refs/remotes/trunk)
$

Now we have Django, push it into our python path

$ cd ~/lib/python
$ ln -s ~/Projects/django/django/
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> django.VERSION
(1, 2, 1, 'final', 0)

Now, let's do the same for South. South is a database migration helper for Django. These are the two things you want to have in any Django at a minimum. There are also plenty of other amazing things like haystack, piston, satchmo, etc. You can follow the same recipie for them too.

$ cd ~/Projects
$ hg clone http://bitbucket.org/andrewgodwin/south/
destination directory: south
requesting all changes
adding changesets
adding manifests
adding file changes
added 802 changesets with 1340 changes to 183 files (+1 heads)
updating to branch default
143 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ~/lib/python
$ ln -s ~/Projects/south/south
$ python 
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import south
>>> south.__version__
'0.7.1'

Finally, we want to be able to create Django projects. There is a great helper called django-admin that will do this. Let's put it into our path

$ cd ~/bin
$ ln -s ~/Projects/django/django/bin/django-admin.py
$ hash -r

That last statment will cause your interpreter to re-read PATH and make anything new available for execution. Now, you should go ahead and create your projects. There are a variety of ways to do this. However what I like to do is keep Django applications separate from the Django project. That way, they can easily be re-used if required. So, for a project called 'foo', we might have

$ mkdir -p ~/Work/foo
$ cd ~/Work/foo
$ mkdir foo.example.com
$ mkdir templates
$ mkdir media
$ mkdir <individual apps>

For each individual app, put them into the Python library. And you then have your re-usability from within Django. For a application called 'bar', you would do:

$ cd ~/Work/foo
$ django-admin.py startapp bar
$ cd ~/lib/python
$ ln -s ~/Work/foo/bar

And now, in your Django foo.example.com setting.py's file you can put 'bar' as one the installed applications and things will Just Work Obviously there are many way to slice this particular mango, but I've found that this works pretty well for me. You can spruce it up by revision controlling each directory in your project (I do) and also take advantage of things like virtualenv and Fabric to make deploying just as easy as developing. But I'll leave those topics until a later date

The 05/2010 issue of the German Linux-Magazin contains an article of mine about DocBook, Subversion and zpub. I was quite surprised to find it there I submitted it in January and did not receive any feedback. But of course it is a nice surprise to find out it was accepted! The article, the zpub website and zpub itself is only available in German so far, but there is an English blog post describing zpub.

Last month I spent two days in Belgium, after I got invited to the MySQL distro meeting. It was a non-public meeting with some people from Sun Microsystems and MySQL maintainers from different Linux distributions. It took place directly after FOSDEM (which I unfortunately could not attend due to personal reasons) at the Sun Microsystems Belgium office in Brussels. It was great to meet with Mathias Gug from the Ubuntu Server team in person. He had some really good ideas on how we could reduce the differences between MySQL in Debian and Ubuntu in the future. As a consequence, Debian will soon switch from Subversion to Bazaar for maintenance of most MySQL packages.

However, we were not only talking about the MySQL Server itself, but also about MySQL Cluster, MySQL Proxy, the MySQL Connectors and the MySQL GUI Tools. Giuseppe Maxia has a more detailed blog entry about the event, including the whole list of participants and some pictures. I fully agree with him: The meeting was a success, we also had a lot of fun, and we should do that more often!

Thanks a lot to Sun Microsystems for sponsoring, and of course to Lenz Grimmer for organizing the event.

So, Debian have kindly funded some new hardware for the AVR32 port, it is the 300 ICnova board, probably one of the best AVR32 boards you can buy to date. The first thing I noticed after finally taking delivery of this a few days ago, it how small it is. I was expecting it to be pretty large, especially seeing as how much stuff it has on it. In fact, it's just smaller than the current NGW100 board I have. So why then new board you ask? Well firstly, I don't own nor have physical access to a board with a display, so this makes testing the all important X server rather difficult [1]. Secondly, the board I currently have is pretty slow due to its lack of RAM, and the fact that it's only 16bit.. This makes using it for porting things rather painful. Finally, the port is getting to the stage where it really needs a porter machine, so that's what this machine will become eventually. Whilst I'm here, I'm going to take this opportunity to prod people about the AVR32 port. ;) The port is currently at a complete standstill since I've run out of buildable packages. This is solely due to the GCC port being buggy (I'm currently fighting with a GCC internal compiler error whilst building Qt4, did I mention that delta is a godsend?) and lots and lots of packages with outdated config. guess,sub files. I currently have around 120 bugs filed for this, so if one of your packages is one of them please fix it. Also, if one of your packages has an Architecture field which avr32 should be in (it should be in most since it's just another linux architecture) please add it. I'd also like to point people at AVR32 dependency status. This is a summary of unbuildable packages and what other packages are stopping them from building (thanks to KiBi for writing this). If you see one of your packages at the bottom of one of the graphs, that means your package is blocking a load of packages from building, and that's bad, m'kay :) I'd very much appreciate help from other people with this, especially for the silly build failures that are trivial to fix. For those who are interested, the port currently stands like this:

• BD-Uninstallable: 2213
• Failed: 495
• Installed: 5336

Now for some useful and interesting AVR32 port related links..

• AVR32 port status
• AVR32 filed bugs
• A pretty graph ;)

Finally, a picture of the new board, and a big thanks to Debian for funding this! [1] Unfortunately X doesn't seem to work at all yet, it just segfaults. :(

Earlier this year, my brother and I developed a documentation management server for a small software developing company. They were sick of creating their documentation by sending around Word documents, having to manually merge them, losing changes and not getting a clean, consistent layout.So we created zpub for them: It is based on DocBook and Subversion, and adds a fairly nice web interface to it. Now their work flow is

1. The editor checks out the DocBook source document via Subversion. With a client like TortoiseSVN, this is possible even for the less tech-savvy editor.
2. He works on the document using the editor of his choice. We recommended an editor with a proper DocBook mode such as the XMLMind XML Editor or Serna Free, which was recently published as Free Software, to our customer.
3. When satisfied, he commits his changes via Subversion, adding a comment describing his modifications.
4. On the server, zpub renders the document in the various output formats (.html, .pdf, .chm), and makes the result available via the web interface. The commit messages are put there, and all previous revisions of the document can still be accessed.
5. Optionally, an e-mail about the change is sent out to a per-document configurable list of recipients.
6. Optionally, the documents are rendered with a DRAFT -Watermark on the pages, to avoid leaking wrong revisions to the outside. Only users with extended rights are allowed to release a document, thus causing a version without that watermark to be rendered.

For more details on the feature and usage of zpub, check out the documentation that you can find on the demo instance.We are actually quite satisfied by zpub, and it would be a petty if that was just it. Of course, there are quite a view programs out that that can provide these features plus many more, much more than a company the size of our customer would want to have (or even to worry about). So there is a niche between sending Word documents by mail and buying a very expensive, complicated product where zpub fits in.Being a fan of Free Software myself, and since zpub is based on Free Software, we decided that we want to release zpub itself under a Free License. We chose the EUPL, which is a GPL compatible license created by the European Commission, since our customer comes from a municipal environment. The code is hosted on gitorious now, so if you have a need for zpub, just give it a try.Also, if you run a Free Software project, manage your documentation in DocBook (or want to start to do so) and think that zpub might be a neat idea to allow more documentation writers to contribute, talk to me. I might well offer free hosting in that case. If you are a commercial user, I m still offering hosting (and support or feature development), just not for free any more. Note that the zpub user interface and documentation is currently only available in German.

I've been using Subversion and Trac for some years now, and I have encouraged its use at work since the last couple of years, with the undesired effect of having to maintain four different Trac installations with different database systems (SQLite3 and PostgreSQL), plugins (more than 15 on the big servers), authentication systems (htpass files, LDAP and a database based system) and tons of projects published (two internal servers have 64 and 16 projects, one of the client system has 33 projects and there is only one single project installation, but it is living at a client's system). Yesterday night, while reading Planet Debian I found a post from John Goerzen about tools to replace Trac, including the option to use Git as the project VCS. In the post he talks about different options, mainly projects that I would categorize as issue tracking systems (mantis, roundup, etc.), but it also talks about Redmine, a project management system implemented using the Ruby on Rails framework that is similar to Trac. As it looked interesting I downloaded, installed and executed an instance in about 15 minutes (I love the systems that support sqlite3 for this quick tests, not having to touch real database servers speeds up simple tests a lot). I played a little bit with the system and I believe that I will spend some more time testing it at work next week, as it looks quite promising; the standard version has almost all the features I'm interested in without the need to install additional plugins and it can do most of the things I was missing from Trac to do lightweight project management. I evaluated ]project-open[ to use it together with Trac for our internal project management tasks, mainly because we miss important features from Trac, like having clean systems to view the tasks of a user in all projects or a clean way to do the project planning using tickets and gantt charts. Of course there are ways to do it, but the plugins I've tried are not as good and simple as I would like. The problem with the use of ]project-open[ is that I don't really like it for us, as it has tons of features that I feel we don't need nor will use and, on a first try, the system seemed difficult to deploy and maintain, probably because my lack of knowledge about OpenACS and TCL. In fact we still don't have ]po[ running at work because I was unable to to integrate the authentication system with our LDAP server on my first tries and have had no time to investigate further since then. The good thing about trying Redmine is that if we don't end up using it at least I can take the most of this opportunity by looking at Ruby on Rails and the Ruby Programming Language, at least from the administration side, as I have never looked at it seriously.

Users of subversion may have noticed that the svn_load_dirs script was removed from Debian due to a lack of a license from upstream. So far, attempts to get a DFSG-free licensed version have failed, so I've begun a new python implementation that is licensed under GPLv2. 0.1 is functional and uses the same syntax as the original, but is missing a few features that prevent it from being a drop-in replacement. I hope to remedy this in the coming weeks.

Switzerland voted today for the introduction of biometric passports, with 50.1% for and 49.9% against, one of the closest votes since 1848 (according to NZZ). While the news don t fill me with glee there are too many unanswered questions around the digital passports one aspect of the decision surprised and even shocked me. I do not like biometric passports, because I like to know when my data are consumed, and by whom. The German government assures that only authorised parties can access those data, and published information about the security features of the German biometric passports, but I am unconvinced that those are adequate to protection for the 10 years of validity of the passport. Furthermore, I could find absolutely no information on who the authorised parties are, or which regulations cover who will become authorised in the near future. If that was properly addressed, e.g. by leaving it up to me and only me to decide who gets access, then the digital passport could actually be a good step forward, streamlining border control and making travel easier. But there is a completely different avenue of concern, no matter who gives permission to whom to consume whose data: how are they used, and where, and how long are they stored, and for what? Again, I cannot find any regulations. Instead, my question to the German Department of the Interior was answered (!) along the lines of it being up to each country to decide themselves over the use and storage of the data. In this light, it makes little difference that the German procedure for the digital passport does not permit the issuing bureau to store the data, while Switzerland s strategy is to build a central database of all these personal details (this is what shocked me). It might make you wonder what use the Swiss government is hoping for, and you might feel uncomfortable with your government building up an even tighter database of its people. But I d much rather have my data stored in Switzerland than consumed and stored every time I enter another country, because when I compare the style of governance of Switzerland to pretty much anything else out there, I am glad I get to live here (even though I am not Swiss and cannot vote). Yet, it s a worrying step in a direction of the glass human , of a society in which personal privacy is unknown and everything is part of the system. These are totalitarian visions, and it s doubtful whether we ll ever actually get there (so far, I don t think any state has come up with the information management strategies required to properly store, make use, and read sense out of the massive amounts of information), but the trend is clearly visible. In the end, however, what worries me the most is how relaxed people treat their personal information these days. Look at the infamous social networking sites, or other Web 2.0 gimmicks and you really start to wonder how headless people can be these days. I cannot immediately paint a scenario where it might be dangerous to push all kinds of information about yourself to the masses, but the mere idea of that is scary in and of itself. I d prefer to have the choice with whom to share what data. The biometric passports, despite the advantages they might bring, are one step away from that, because they empower the government to make that choice for you. I don t consider that progress at all. Update: NZZ reports that the issue is not closed. In the cantons of Grishuna and Lucerne, people are challenging the vote and a recount or even re-vote seems possible. I will post an update as soon as I know more. Then, I would also like to address some replies I ve received over the real problems behind the digital passports, because it cannot be just the central data storage it s not like your government doesn t already have all that, and I can t imagine how your fingerprint could be used against you.

You are wondering if forgot my password of the blogging account? No I didn't, I just don't have much time to do blogging. I try to invest more time to just do things than to talk about what I have done or will do. Blogging needs time: you need a topic to blog about, you have to login, make a point, do spellchecking and so on. The result: you see about every 3 months a blog post from me. Don't get me wrong, I am doing geeky stuff every single day (except when I am on vacation maybe, but that was how many years ago, eh?).
Micro-Blogging to the rescue! You probably know micro-blogging ala twitter.com already, but for me thats something new You just post a single message with no more than 140 characters and you are done. So if you want to follow my activities, feel free to subscribe to my micro-blog found on twitter: http://twitter.com/meebey Smuxi is doing nice progress now, I made 2 important changes to archive constant progress: switch from Subversion to Git and with that switch from Trac to Redmine. Now everything is kept in feature-branches and I can switch more often between features and bug fixes without messing all up. More details about this can be found in this Smuxi blog post.

This is my first entry from my Acer Aspire1 since installing the latest Emdebian Grip and the 2.6.28 kernel that now provides free wireless support. A few tweaks still needed to get a few packages sorted out so I've got a Debian source on this box too. Still, with my usual packages (iceweasel, sylpheed, grisbi, geany), all my email cached data, liferea data, a few documents and a few Debian packages and I'm still at only 753Mb used.

Using wicd from squeeze, I've got wireless working - there's no led lit but I'm sure that's fixable.

Copying a few files around from ~/.gnome2/ on my other laptop and suddenly I have drivel, sylpheed and liferea all pre-configured.

I'll be blitzing this install again numerous times in the next few days but by keeping the ~/.gnome2/ files on a USB stick, it will be simple to restore the system, especially as I'm using IMAP email.

(If you're wondering, the drivel upload is delayed by the churn in Debian Sid - waiting for the libmtp7 8 transition to make rhythmbox available in a clean chroot.)

From tomorrow, if you start seeing bugs or getting email about your packages where the version string ends in em[0-9], or where dependencies mentioned by reportbug include such a version suffix, the user is running one of the two Emdebian distributions to be released alongside lenny (and based on lenny packages). You might also see Emdebian in the output of 'apt-cache policy' if your bug reports request or supply such data.

If there is any doubt that the bug is present in Debian, please immediately re-assign the bug to the buildd.emdebian.org pseudo-package in the BTS.

I'll be posting to d-d-a with more information on the releases and the em1 version suffix - just as soon as Lenny itself is released.

A patch for reportbug is being tested and I'll file the bug probably tomorrow. A large proportion of the development work to actually get Emdebian to the point of two releases only happened after the lenny freeze began. (Not the recent deep freeze, the initial toolchain freeze before DebConf8). (reportbug itself is not currently part of Emdebian for a variety of reasons.)

Emdebian only uses a small subset of Debian packages, so this principally involves the core packages in Debian, GTK+2.0 and dependencies, XFCE and GPE as well as a small number of applications like iceweasel, sylpheed, xchat-gnome and grisbi.

The two Emdebian distributions will be:

Emdebian Grip 1.0 (lenny)

A small Debian-compatible Emdebian installation

Full release title:

    Emdebian GNU/Linux Grip 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name: 

    Emdebian Grip 1.0 (lenny)

Common release names:

    Emdebian Grip or Grip (lenny)

Architectures: i386, amd64, powerpc, arm, armel, mips and mipsel

Emdebian Grip explicitly supports mixing Debian and Emdebian and that is how a Debian package could end up depending on a package from Emdebian Grip - this is not expected to be a problem because Grip packages are binary-compatible with the Debian version, just with some files removed from the package. (i.e. Grip is post-processed, not recompiled.) Grip typically comes in at ~600Mb for a full XFCE desktop and uses the Lenny debian-installer images. (Grip base system ~250Mb.) I'm currently running Emdebian Grip on my Acer Aspire1.

More information: http://www.emdebian.org/grip/

Emdebian Crush 1.0 (lenny)

The smallest Emdebian installation - cross-built from Debian sources.

Full release title:

    Emdebian GNU/Linux Crush 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name:

    Emdebian Crush 1.0 (lenny)

Common release names:

    Emdebian Crush or Crush (lenny) 

Architectures: arm only 

More information: http://www.emdebian.org/crush/

Crush is the cross-built distribution from Emdebian - significant functional changes exist compared to the Debian package, libraries have been recompiled with options turned off and functionality removed etc. and Crush has dropped support for python or perl, and uses a modified, more recent version of busybox instead of coreutils. Crush is the hardest distribution to install, maintain and update and requires extensive customisation for particular machines with the benefit that it is an ultimately flexible Debian where the base system (equivalent to a debootstrap in Debian) can fit into 24Mb installed and a GPE GUI in 75Mb. uClibc support is expected in Crush 2.0 (squeeze), allowing sizes to shrink by another 10Mb or so. I'm currently running Emdebian Crush on my balloon3.

Amora ( A MObile Remote Assistant ) is a client/server suite which allows you to remote control an X desktop using a bluetooth enabled mobile phone. Initially there was only a Symbian client (running e.g. on nearly all Nokia E and N series phones), but J2ME clients are under developement, too. Then there is Tablet Amora (aka Tamora), an Amora proof of concept client for the Maemo platform which runs on internet tablets like e.g. the linux based Nokia N770, N800, and N810. Since Maemo isn t that far away from what runs on the OpenMoko, getting Tamora working on the OpenMoko, too, suggested itself. Maemo seems to use the deb package format, too, just slightly extended (e.g. by package icons), so it wasn t even that hard work to adapt the existing Maemo packaging to build, install and run on Debian, too. So that s how Tamora looks on the OpenMoko: The packaging is still far away from Debian standards (throws tons of lintian warnings and the source package generation is b0rked), so yet there are no prebuilt debs available, but you can checkout amora-client from the Subversion repository and build the package from there:

 $ svn checkout http://amora.googlecode.com/svn/trunk/amora-client/maemo/ amora-client
 $ cd amora-client
 $ debuild -uc -us
 $ cd ..
 # dpkg -i amora-client_0.1-2maemo+openmoko_all.deb

For running and installing tamora you need packages from the pkg-fso APT repository on alioth. And to build it, you need the libedje-bin which is available from the pkg-fso repository for at least the armel architecture, or else from Debian experimental. You can add these repositories to your sources.list as follows:

 # PKG FSO repository
 deb     http://pkg-fso.alioth.debian.org/debian unstable main
 deb-src http://pkg-fso.alioth.debian.org/debian unstable main
 # Debian Experimental
 deb     http://ftp.ch.debian.org/debian experimental main
 deb-src http://ftp.ch.debian.org/debian experimental main

Since Tamora is yet only a proof of concept client, currently only the following remote functions are available:

• pressing arrow key right/left
• pressing F5 (fullscreen for the OpenOffice.org Presenter)

This should though at least suffice for a presentation with the OpenOffice.org Presenter. To use Tamora to remote control your Debian laptop, you need a bluetooth dongle (or builtin bluetooth support) and amora-server installed as with the Symbian S60 (3rd Edition) Amora client, too. Update, 23:51 libedje-bin seem not available in the pkg-fso repository for every architecture. You ll also find it in Debian experimental. Updated the sources.list section above appropriately. Thanks to Sebastian Montini for pointing out this problem.

Since Debconf 6, organizing a series of BOF dedicated to i18n-related topics has proven to be quite useful to all people working on i18n/l10n in the project.

Traditionnally, session 1 is an open talk/round table meant to enlighten the topics to be discussed in other meetings (as well as more informal work sessions during the conference).

Session 1 would be "opening session" as well as the first "work session"

churro: status of server

Services on churro:
(listed on http://i18n.debian.net/wiki)

- l10n material collection: status by nekral
what does it cover (unstable/testing, po-debconf/po/?)
what is using it?

- Pootle. define admins
bubulle: explain what's currently and what's in production
D-I: direct commits to SVN. Missing projects
Debconf: interaction with debian-l10n SVN, need for tools to
grab l10n from SVN. Integrate in po2debconf?

- DDTP: grisu gives status
what about PO export/import
bubulle about PO import to Pootle and perf problems
ddtss: nekral?

- tracking robots: status by nekral

- compendia: status by bubulle

- stats and graphics: status by nekral
Organize this? (pointers on main l10n page?)
Move stats pages to churro?

Server administration and hosting: status by faw
- server admin ML: use d-l-devel?
- move to i18n.debian.org: blockers?
Full event details